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Legal Notice 


IMPORTANT 
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Warning 
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About this guide 


“ASE and Extended debug stubs” provides detailed background information about the two 
debug stubs and their differences. 


“Interrupts and Exceptions” provides details of how interrupts and exceptions are implemented 
under different debugging environments and considerations when writing your own exception 
handler. 


“Communications Channels” provides an overview of channels and how they are accessed from 
the target and host using ASE BIOS services and the CPDIAL library respectively. 


“ASE BIOS services” describes ASE BIOS calls and channel interrupts used to access channels 
from the target and gives code examples. 


“CPDIAL Library Reference” describes the Debug Interface Adapter Library, including the CDIAL 
C++ class definitions, and how to use its functions to access channels from the host. 


“Appendix A: Writing an SH4 Boot ROM” describes the considerations when writing a Boot 
ROM. 


About this guide 


ASE and Extended debug 
stubs 


The debug stub has two parts, the ASE debug stub and the Extended debug stub. Two stubs are 
required because ASE memory is limited to 1kbyte and is insufficient to provide all the required 
functionality. The Extended debug stub, due to its size, must be resident in external RAM. 


The two stubs and their environment requirements are discussed in this chapter. 


The ASE debug stub 


The ASE debug stub resides in the SH4’s 1kbyte of ASE memory. This memory cannot be 
physically read or written to by the application code, it can only be accessed in ASE mode by 
the debug tools. The ASE debug stub is a minimal debug stub loaded into ASE RAM after a 
target system reset. The purpose of the ASE debug stub is to facilitate basic debugging, system 
initialisation and the loading of the larger and functionally complete Extended debug stub. 
Once the Extended debug stub is loaded the ASE debug stub is used simply to chain ASE 
exceptions to handlers within the Extended debug stub. The ASE debug stub and ASE RAM are 
transparent to the application. 


The Extended debug stub 


The Extended debug stub resides in RAM and requires 16kbytes of memory. This debug stub 
contains all the necessary functionality to provide comprehensive debugging of the target. The 
debug stub memory is not protected from corruption by the application code, thus the 
application must not under any circumstance attempt to utilise the memory space allotted to 
the Extended debug stub. An errant piece of application code can write over the Extended debug 
stub causing it to fail. Under these circumstances the debug stub (and debug session in progress) 
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must be reloaded and restarted. The Extended debug stub has its own private stack within the 
boundaries of the allotted 16kbytes of RAM and thus does not require use of the application 
program’s stack. 


The location of the Extended debug stub is defined either by the Boot ROM code, or by the 
settings in the Start-up configuration dialog of CodeScape. 


The Extended debug stub can also be identified by the three instructions at the start of the 
16kbyte section, which are always BRK, RTE, NOP; instruction codes 0x003B, OxOOOB, and 
0x0009. 


Byte sequence: 
© 0x3B, 0x00, OxOB, 0x00, 0x09, 0x00 - little endian Extended debug stub 
°¢ 0x00, 0x3B, 0x00, OxOB, 0x00, 0x09 - big endian Extended debug stub 


Functional differences of the ASE and Extended 
debug stubs 


The table below lists the differences in functionality of the two stubs. 


Extended ASE debug 
Function debug stub stub Comments 


Read/Write memory yes yes Extended: Optimized for speed. 
ASE: Optimized for size. 


Extended: Handled by the Extended 
debug stub. 


ASE: Handled by the DA (much slower). 


Write memory cache coherency 
maintained. 


Read/Write General purpose 


registers. 
Read/Write Floating point registers yes 
Read/Write UBC registers yes Extended: Optimized for speed. 
ASE: Achieved by multiple memory R/W 
accesses (much slower). 


Extended: Optimized for speed. 


ASE: Achieved by multiple memory R/W 
accesses (much slower). 


| Read/Write HBC registers 
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Extended ASE debug 
Function debug stub = stub Comments 


Read/Write MMU registers. yes yes Extended: Optimized for speed. 


ASE: Achieved by multiple memory R/W 
accesses (much slower). 


ASE: Store queue info not available. 


Extended: Located wholly within the 


Default exception handler at VBR. yes 
boundaries of the 16kbytes allotted. 


Extended: Uses default exception 
handler. 


ASE: Uses SH4’s trace mechanism. 


< 
mM 
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Catch exceptions at VBR + 0x 100. yes 


Catch exceptions at VBR + 0x400. yes yes Extended: Uses default exception 
handler. 


ASE: Uses SH4’s trace mechanism. 


Catch interrupts at VBR + 0x600. yes yes Extended: Uses default exception 
handler. 


ASE: Uses SH4’s trace mechanism. 


BIOS calls for utility functions. yes no 
Supports little endian systems. yes yes Extended: DA detects the endianness of 


the target and loads a little endian 
Extended debug stub when required. 


ASE: ASE RAM is always big endian. 


Supports big endian systems yes Extended: DA detects the endianness of 
the target and loads a big endian 
Extended debug stub when required. 


ASE: ASE RAM is always big endian. 


Require system memory to be yes Extended: Requires 16kbytes (anywhere 
present and configured. in RAM). 
ASE: Required no RAM at all. 


Facilitates debugging of code in yes 
ROM. 
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Extended ASE debug 
Function debug stub stub Comments 


Facilitates debugging of code in 
RAM. 


Facilitates the use of software 
breakpoints 


Facilitates the use of hardware 
breakpoints 


ROMless system ‘bring up’. 
RAMless system ‘investigation’. 


ASE mode used for debugging. Extended: Vectored into from ASE RAM. 
ASE: Used inherently. 


Hitachi SH4 FPU exception handled. Extended: Transparent to user (code 
execution slowed down). 

ASE: Exception reported (handled by 
CodeScape). 


Stub memory protected for 
application code. 


Optimization of the stubs 


The ASE debug stub must fit entirely into 1kbyte (512 instructions), for this reason all of the 
ASE debug stub’s functions are optimized for size. In some cases functionality is delegated from 
the ASE debug stub to the Debug Adapter (DA). 


An example of this is the Read Context HBC’. This is a command issued by CodeScape to 
request that the values of all of the HBC’s (hardware break controller) memory mapped registers 
are returned. 


In the Extended debug stub, a protocol exists for this purpose. The DA requests the HBC’s 
context and the Extended debug stub replies by reading the required registers and returning 
them in a single transaction. 


In the ASE debug stub no such protocol exists between the DA and the ASE debug stub, however 
the same result is achieved by the DA issuing a series of "Read Memory’ commands to read each 
of the individual registers one by one. 
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The DA and Extended debug stub performs the HBC context read in the most efficient (fastest) 
method possible whereas the DA and the ASE debug stub performs the HBC context read using 
the minimum amount of code in the ASE debug stub. The net result is that the Extended debug 
stub runs much faster than the ASE debug stub. 


Exception handling in the ASE debug stub 


The ASE debug stub uses the SH4’s Branch Trace mechanism to allow exceptions and interrupts 
to be caught. The Branch Trace mechanism is part of the SH4’s on-chip hardware debugging 
tools. This allows the ASE debug stub to be entered, via an ASE Trace exception, when a 
particular condition is met. 


The Trace Branch mechanism is set up to cause the stub to be entered when either; an exception 
to VBR + 0x100, an exception to VBR + 0x400, an interrupt to VBR + 0x600 or an RTE 
instruction is executed. When the stub is entered due to the one the above Branch Trace events 
occurring the following action is taken: 


The Branch Trace events VBR + 0x600 and RTE are usually not required as far as the user is 
concerned, but they must be handled because the SH4’s Branch Trace mechanism does allow 
individual branch types to be selected. Thus for VBR + 0x600 and RTE, the DA instructs the ASE 
debug stub to simply return program control back to the application program. 


If the ASE debug stub is being used to debug an application that uses interrupt VBR + 0x600 
and its associated RTE, there will be a time penalty due to the ‘filtering’ effect of processing this 
unwanted exception. 


When using the ASE debug stub for debugging, if you do not want the ASE debug stub to catch 
any exceptions, then it is possible to turn off the Branch Trace mechanism entirely. This is 
achieved using CodeScape (from a memory window) to write a single byte 0x00 to the ‘Trace 
Memory Control Register’ at address OxFF2000BC. It should be noted that without the Branch 
Trace mechanism, the ASE debug stub will no longer be able to catch any exceptions (including 
ones such as Address Error etc.) and in CodeScape you will be limited to using hardware and 
software breakpoints and basic trace functions such as single stepping. 


ASE and Extended debug stubs 


Exception handling in the Extended debug stub 


The Extended debug stub handles exceptions and interrupts by installing a default exception 
handler which sets up the VBR register accordingly. Alternatively, you can use your own 
application exception handler, see “Interrupts and Exceptions” on page 11. 


Debug stub cache usage 


Caching during BIOS calls 


When a BIOS call is made the debug stub runs from the SH4’s P1 area (cacheable). If the SH4’s 
cache is enabled then the speed of the BIOS call is improved due to the debug stub being in a 
cacheable area. The debug stub does not implicitly enable the cache during a BIOS call. 


Cache coherency for the 'Write Memory’ command 


Cache coherency for writing to the SH4’s memory is maintained for both the ASE debug stub 
and the Extended debug stub. The basic method used to achieve this is: 


¢ The CCR (cache control register) is put into ‘write through’ mode before actually 
writing to the SH4’s memory, write to the memory, then return the CCR to its 
original state. 


¢ Before ‘resuming’ running the application code (after a memory write), the 
instruction cache is flushed. 


For the Extended debug stub 


The manipulation of the CCR for the Extended debug stub is done entirely in the Extended 
debug stub’s ‘Write Memory’ command. If a memory write to the SH4 has been issued by the 
DA then the following sequence of events is executed: 


e Prior to the memory write the current CCR (cache control register) value is saved. 
e The cache is put into write through mode. 

e The memory write is carried out. 

e The CCR is returned to its original value. 


At the end of the debug session (the series of commands issued when in the debug stub prior 
to resuming the application code) the instruction cache is invalidated. 
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For the ASE debug stub 


For the ASE debug stub, the CCR is manipulated by the DA issuing "Read Memory’ and "Write 
Memory’ commands to read and write the CCR register before and after issuing the actual "Write 
Memory’ command itself. Using this method the ASE debug stub’s Write Memory’ command 

does not need any code to handle cache coherency, however, the performance is degraded due 
to the overhead of the DA issuing the additional commands. 
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Interrupts and Exceptions 


This section deals with issues concerning exception and interrupt handling on the target and 
the interaction and interrupt requirements of the debug stub. 


Exception handling with or without a Boot ROM 


Halt or Resume after stub load 


Once the Extended debug stub has loaded, the Debug Adapter (DA) instructs the debug stub to 
either resume execution of the Boot ROM (if one is installed), or set up a default environment 
and wait for the user to perform some action such as downloading a program. This is controlled 
by the option: Halt after stub load on the Start-up options dialog box in CodeScape. 


The debug stub implements exceptions using different methods depending on this condition. 


Resume (debugging with a Boot ROM) 


This mode exists to allow program execution to resume back to the Boot ROM after the 
Extended debug stub is loaded. This is achieved with the minimum of disruption to the state of 
the target microprocessor context. 


However the following changes will have been made to the context after resuming: 


e The DBR register is loaded with the default debug stub exception handler. 
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Halt (debugging without a Boot ROM) 


This mode exists to allow the Extended debug stub to be loaded and then the context to be set 
up with default settings to allow a debugging session to commence. In this mode CodeScape 
does not pass program control back to the Boot ROM, instead, control remains within the debug 
stub monitor. 


¢ The DBR register is loaded with the default debug stub exception handler. 
e The VBR register is loaded with the default debug stub exception handler. 
e The stack pointer is loaded at Ox0d000000. 


e The status register block bit is cleared to 0. 


Exceptions during debugging with a Boot ROM 


When ‘resume after stub load’ mode has been selected, the debug stub does not implement a 
exception or interrupt handler of its own and it does not alter or set up the VBR register. Thus 
the debug stub makes no demands of the application code and does not introduce any time 
penalties by running debug stub exception handler code. However, this does mean that the 
application code must implement its own handler if exceptions or interrupts are to be used by 
the application code itself. 


To allow the debug stub the ability to process exceptions (not interrupts, see “Interrupts during 
debugging” on page 14.) in this mode, the debug stub incorporates a passback facility to allow 
unhandled exceptions to be caught and processed by the debug stub. To implement the passback 
facility the application code exception handler must call the debug stub using the following 
sequence of instructions. 


For exceptions (VBR + 0x100 and VBR + 400) the passback call takes the form: 


BRK 
RTE 
RTE 
NOP 


This special sequence causes the debug stub to be entered via the BRK’ instruction and the 
double ‘RTE’ immediately after the break indicates to the debug stub that this is an exception 
passback call. 


This sequence should be added to the end of the application code exception handler to allow 
the debug stub to process any unhandled exceptions. The NOP’ at the end is not strictly required 
but can be added to inhibit compiler or assembler errors. You should use the passback sequence 
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where you would normally put code to deal with unhandled exceptions. Where an exception 
has been handled correctly by the application code, then an 'RTE’ must be executed rather than 
the passback sequence. 


Notes: 


1. After the debug stub processes an unhandled exception, the program execution is 
returned to the interrupted code, control is not returned to the application exception 
handler. Thus no attempt is made to try and execute the ’RTE RTE’ element of the 
passback sequence. 


2. Some assemblers and compilers may not allow an RTE opcode following an RTE 
opcode. In this event the following sequence could be used: 


BRK 
RTE 
DC.W 0x002b 
NOP 


3. Unhandled exceptions passed back to the debug stub are reported to CodeScape and 
this in turn is interpreted and reported as specified by CodeScape. 


4, The application code must take care to ensure the SR.BL block bit is handled correctly 
to ensure exceptions are accepted (see the Hitachi SH4 hardware manual for further 
details). 


5. For the passback facility to function correctly the application code must not change 
the contents of the EXPEVT register prior to issuing the passback call. 


Exceptions during debugging without a Boot ROM 


When ’halt after stub load’ mode has been selected, the debug stub implements a default 
exception and interrupt handler by initialising the VBR register to point at the debug stub 
default handler. 


The default handler allows all exceptions and interrupts to be caught by the debug stub and in 
turn reported by CodeScape. This allows application code to be debugged without the need for 
an application code handler to catch exceptions such as ’address error’ etc. 


The application code can at any time install its own handler by changing the contents of the 

VBR. Once this is done the debug stub default handler will no longer function but application 
code can utilise the passback method as described in the previous section to allow unhandled 
exceptions to be handled by the debug stub. 


Interrupts and Exceptions 


If the VBR is changed by the application code, the debug stub will make no attempt to restore 
the VBR to point at the debug stub default handler. However the application code can restore 
the VBR to the default value to make the default handler functional again. 


Notes: 


1. If *halt after stub load’ debugging mode is selected the SR.BL block bit defaults to 0. 


Interrupts during debugging 


An additional specific passback sequence is available to allow unhandled interrupts (not 
exceptions) to be captured and reported to CodeScape. To implement this passback facility the 
application code interrupt handler must call the debug stub using the following sequence of 
instructions. 


BRK 
RTE 
RTS 
NOP 


The above sequence should be implemented in a similar manner to the exception passback 
sequence described above. This sequence must only be used to passback unhandled interrupts 
for the interrupt handler at the address VBR + 0x600. 


Caveats and limitations 


Use of the HBC registers 


CodeScape makes use of the HBC unit to implement hardware breakpoints, for this reason the 
application code must not attempt to access the HBC’s registers. 


Debugging exception handlers using CodeScape 


It is possible to ‘lose’ hardware breakpoints when debugging application exception handlers. 
This occurs if the handler routine being debugged does not allow for nested exceptions to occur. 
A nested exception is required in this instance to allow the HBC exception to be accepted and 
the debug stub default handler to be called. It is recommended that software breakpoints are 
used where possible when debugging exception handlers. 


Consult the Hitachi SH4 hardware manual for information on allowing nested interrupts to 
occur, however the following notes outline the basic methodology. On entering the application 
exception handler: 
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1. Save the SPC to a temporary location. 
Save the SSR to a temporary location. 
Clear the SR.BL bit to 0 (this now allows exceptions or interrupts to occur). 


Execute the application exception handler code. 
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Set the SR.BL bit to 1. (this inhibits exceptions or interrupts from occurring when 
restoring the SPC and SSR). 


6. Restore the SSR to the original value from the temporary location. 
7. Restore the SPC to the original value from the temporary location. 
8. RTE 

Notes: 


1. Ifan interrupt occurs within the exception handler prior to the SR.BL bit being cleared, 
then it will be held until the SR.BL bit is cleared. 


2. Ifan exception occurs within the exception handler prior to the SR.BL bit being cleared 
or after it has been set, then it will cause a manual reset to occur causing program 
execution to transfer to the reset vector (highly undesirable). This situation will occur 
if the exception handler contains a programming error in the code such as an 
instruction address error. Care must be taken with writing application exception 
handlers to ensure no such errors exist, specifically when the SR.BL bit is set. 


Performance loss when handling SH4 FPU exceptions 


If the enable bit for underflow, overflow and inexact in the FPSCR registers is set, the processor 
reports an exception for all operations that can possibly generate the desired exception, 
regardless of whether an error is detected. It is the exception handler’s responsibility to 
differentiate between real and false exceptions by masking together the cause and enable bits 
of the FPSCR register. 


To alleviate this problem the Extended debug stub checks these bits and ignores false exceptions. 
Processing exceptions for every floating point operation can seriously impact on the 
performance of the processor. 


The ASE debug stub cannot process the exceptions and relies on CodeScape to handle the 
problem. The process of stopping the processor and waiting for the debugger to service the 
exception produces an even larger degradation in performance. 


Interrupts and Exceptions 
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Communications Channels 


About channels 


Channels provide a means of fast communication between the host and the target. There are 
four high-speed bi-directional channels allowing communication between host and target 
applications at speeds in excess of 500kbytes/s. Each channel may be read from and written to 
independently either a byte at a time or in blocks. 


Channels are implemented via the JTAG interface from the target to the Debug Adapter (DA) 
and via Ethernet from the DA to your computer. The DA has eight 128kbyte buffers to provide 
an input and output buffer for each channel to ensure uninterrupted communication. 


The following chapters describe in detail the ASE BIOS services and DIAL library functions and 
give code examples where appropriate. 


NOTE: At the time of writing, you cannot use channels with Microsoft® Windows® CE. 


Channel access 


Target access 

Channels are accessed from the target using the ASE BIOS services. These services allow 
communication between the target and the DA via the JTAG interface. 

Host access 


Channels are accessed from the host using the Debug Interface Adapter Library (DIAL). This 
library provides communication between the host and the DA via the SCSI interface. 


Communications Channels 
Channel designation 
The channels are reserved for use as follows: 


Channel 
Number 


Operating System debugging interface. Currently 
this channel is spare. 


Channel buffers 


The DA contains eight 128kbyte buffers to ensure uninterrupted data transfer between the target 
and host. Each of the four channels has a host-to-target and a target-to-host buffer as shown: 


Host DASH 


Channel 0 


Channel 1 


SR Sis 


Channel 2 


Channel 3 
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This section describes the ASE BIOS calls used to access channels from the target, channel 
interrupts and code examples. 


Target channel access 
Channel access from the target to the application is implemented using either: 
e ASE BIOS calls made by the application software to the debug stub. 
-OR- 
e Interrupts issued by the DA debug stub to the target application interrupt handler. 


The ASE BIOS calls are non-blocking to allow the target application to issue a BIOS call and 
receive a reply immediately. The return values of the reply indicate the success or failure to carry 
out the requested task. 


BIOS calls 


Six ASE BIOS calls are available for use by the application software, these are: 
e Read byte, INCHR. 
e Write byte, OUTCHR. 
e Read buffer, RDBF. 
e Write buffer, WRBF. 
e Read channel buffer status, RDSTAT. 


e Set and read channel interrupts, CHISR. 
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Interrupts 


The DA can issue an interrupt to the target application interrupt handler when a specified 
channel buffer condition is met, see “Set and Read Channel Interrupts, CHISR” on page 28. 


Accessing ASE BIOS services 
In privileged mode the ASE BIOS services are accessed by: 

1. Loading registers R4, R5, R6, R7 with the required parameters. 

2. JSR to the start address of the debug stub, ASE_BIOS in the examples. 
In user mode the ASE BIOS services are accessed by: 

1. Loading registers R4, R5, R6, R7 with parameters. 

2. TRAPA #02. 


Notes: 


1. ASE BIOS services are provided by the Extended debug stub resident in target system 
RAM. The ASE debug stub provides just one service, “Instruct the DA where to load 
the Extended stub”. 


2. The ASE BIOS accepts any value for the destination address, therefore calling code 
should validate the supplied parameters in the TRAPA handler. 


3. If.an application exception handler is in use, the debug stub exception passback must 
be implemented to allow the TRAPA #02 to be handled by the debug stub. The 
application exception handler must not alter the values of EXPEVT and TRA prior to 
issuing the passback call. 


4. In privileged mode the TRAPA #02 instruction can also be used to issue a BIOS call 
subject to the same validation as above. 


5. BIOS calls can be issued using TRAPA #02 when the debug stub’s default exception 
handler is in use. In this instance the default handler will issue the BIOS call in a 
way that is transparent to the application code. 
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Setup registers 


To use the ASE BIOS services, set up the registers as shown in the following table. Request the 
service by a JSR to the start address of the debug stub, ASE_BIOS, if in privileged mode, or a 
TRAPA #02 if in user mode. 


Description 


Read byte OxOA00 + Not used. Not used. Not used. Not used. 
Channel 
Number. 


OUTCHR Write byte. OxOBOO + Not used. Not used. Not used. 
Channel 


Number. 


Read buffer. OxOA08 + Maximum Destination Address of Number of 
Channel read size. address. LOC. bytes read. 


Number. 


Write buffer. OxOBO8 + Number of Source Address of Number 
Channel bytes to address. LOC. of bytes 
Number. write. written. 


RDSTAT Read channel Ox0COO + Not used. Not used. Address of Status. 
buffer status. Channel Loc. 


Number. 


Results 


After the BIOS call, RO and LOC hold the results as follows: 


Operation 


Byte read in low word, error code in high word. 


INCHR 


Not used. 


OUTCHR Error code in high word. 


Error code in high word. Number of bytes read. 


Error code in high word. 
Error code in high word. 


Number of bytes written. 


RDSTAT Data available, space available. 
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Error codes 


There are nine possible error codes, stored in the high order 16 bits of RO: 


Name Value Meaning 


CONAOK 0 No error, the operation was successful. 
CONERR ] Fatal error. The DA suffered an internal error. 


CONPRM 3 Parameter error. A buffer count of zero was requested. 
CONADR Bad address. 


CONCNT Bad count. A buffer count exceeding the maximum allowable value was requested. 


The current maximum value is 65536 bytes. 
CONCBF 


CONCBE 7 Channel buffer empty. The application is informed that there was no data to read. 
CONBSY | oe | Channel busy. 


NOTE: An ASE BIOS call may use a subset of the above codes for its return codes. 


Channel buffer full. If there is insufficient space to write all the requested number of 
bytes, then as much data will be written as possible. When the buffer is full the 
application is informed that no further data was written because there was no more 
space available. 
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ASE BIOS calls 


Read byte, INCHR 


Reads a single byte of data from the specified channel buffer to the target. 


Call parameters 


OxAO00 + channel (0,1,2,3) 


Not used. 


Not used. 


Not used. 


Not used. 


Returned data 


RO In high order 16 bits, one of: 
CONAOK, No error. 

CONCBE, channel buffer 
empty. 

CONERR, fatal error. 

Byte read in low order 8 bits. 


LOC Not used. 
ee EE 


Example BIOS call 
; OS (Channel 0) issue a 'read byte non-blocking’ BIOS call. 


mov. 1 #(INCHR + OS),r4 ;BIOS command + channel (0xA00 + 0). 
mov. 1 #STUBSTART, 19 ;Point at the stub start. 

jer @r9g ;Issue BIOS call 

nop 


; After call: 
Byte Read returned in low word RO. 
Error code returned in high word RO. 


, 


, 
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Write byte, OUTCHR 


Writes a single byte of data from the target to the specified channel buffer. 


Call parameters 


Returned data 


In high order 16 bits, one of: 
CONAOK, No error. 
CONCBF, Channel buffer full. 
CONERR, Fatal error. 


Example BIOS call 
; OS (Channel 0) issue a 'write byte non-blocking' BIOS call. 


mov.1 #(OUTCHR + OS) ,r4 ;BIOS command + channel (0xBOO + 0). 
mov.l #0xa5,r5 ;Byte to write (e.g. Oxa5). 

mov.l #STUBSTART,r9 ;Point at the stub start. 

jsr @r9 ;Issue BIOS call 

nop 


; After call: 
; Error code returned in high word RO. 
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Read buffer, RDBF 


Reads a number of bytes of channel data, up to a specified maximum. 


OxA08 + channel (0,1,2,3). 


Byte Count. The maximum transfer size of data to be 
read from the specified channel buffer, up to a 
maximum of 65536 bytes. 


Call parameters 
Destination address of data read from the specified 
channel buffer. 


Zero, or address of LOC to put Byte Count. 
Loc Zero or a 32-bit address to store the actual number of 
bytes read from the specified channel buffer. 


Returned data 


In high order 16 bits, one of: 
CONAOK, No error. 
CONPRM, Bad parameter. 
CONCNT, Bad count. 
CONCBE, Channel buffer empty. 
CONERR, Fatal error. 

channel buffer was empty. 


Example BIOS call 


; OS (Channel 0) issue a 'read buffer non-blocking' BIOS call. 
mov.l1 #(RDBF + OS),r4 ;BIOS command + channel (0xA08 + 0). 


mov.l #200,r5 ;Max number of bytes to read. 
mov.l1 #buffer,r6 ;Pointer to destination buffer area. 
mov.1 #loc,r7 ;Location to report actual number 
;of bytes read after BIOS call. 

mov.l1 #STUBSTART,r9 ;Point at the stub start. 
jsr @r9g ;Issue BIOS call 
nop 

After call: 


Error code returned in high word R8. 
'Loc' contains the number of bytes read. 
'buffer' contains 'loc' number of data bytes read. 


25 


ASE BIOS services 


Write buffer, WRBF 


Writes a number of bytes, up to a specified maximum, to the specified channel buffer. 


Call parameters 


OxBO8 + channel (0,1,2,3). 


Byte Count. The number of bytes to be written to the 
specified channel buffer, up to a maximum of 65536 
bytes. 


Source address. The address in target memory to read 
data from. 


Zero, or address of LOC to put the Byte Count. If this 
value is non-zero, then the value points to a 32-bit 
location to store the actual number of bytes written 
to the DA buffer. 


32-bit location to hold the number of bytes 
transferred. 


Returned data 


In high order 16 bits, one of: 
CONAOK, No error. 

CONCBF, Channel buffer full. 
CONERR, Fatal error. 


Number of bytes actually written (32 bits) or zero if 
the specified channel buffer was full. 


Example BIOS call 


; OS (Channel 0) issue a ‘write buffer non-blocking' BIOS call. 


mov.1 #(WRBF + OS),r4 ;BIOS command + channel (0xBO8 + 0). 

mov.l1 #200,r5 ;Max number of bytes to write. 

mov.l1 #buffer,ré6 ;Pointer to source buffer area. 

mov.l1 #loc,r7 ;Location to report actual number 
;of bytes written after BIOS call. 

mov.1 #STUBSTART,r9 ;Point at the stub start. 

jsr @r9 ;Issue BIOS call 

nop 


; After call: 
; Error code returned in high word R8. 
; 'Loc' contains the number of bytes written. 
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Read channel buffer status, RDSTAT 


Informs the target application of amount of data available to be read from and space available 
to be written to in the specified channel buffer. 


Call parameters 


pee | OxCOO + channel (0, 1,2,3). 
fee 
Ce 


Address of LOC to buffer status information. 


64-bit location to hold bytes of data available 
(long), bytes of space available (long). 


Returned data 


fe [ 
Loc 64-bit location to hold bytes of data available (long), followed 
by bytes of space available (long). 


Example BIOS call 
; OS (Channel 0) issue a 'read channel buffer status' BIOS call. 


mov.l #(RDSTAT + OS) ,r4 ;BIOS command + channel (0xC00 + 0). 

mov.l1 #loc,r7 ;Location to report the actual 
;status information 

mov.l1 #STUBSTART,r9 ;Point at the stub start. 

jsr @r9g ;Issue BIOS call 

nop 


After call: 

Error code returned in high word R8. 

'Loc' (long) contains the number of bytes available to be read. 
'Loc'+4 (long) contains the space in bytes available for writing. 
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Set and Read Channel Interrupts, CHISR 


Use CHISR to service buffers: 


¢ Request a Hitachi-UDI (HUDI) interrupt if a transmitting buffer is empty or a receiving 
buffer is full. 


° Determine if data is present in a channel buffer. 


e Acknowledge receipt of HUDI interrupts by the application interrupt handler. 


Call Parameters 


Name 


IPISET! 


[PACK 


OPISET? 


CHISR = 0x900 


Address of a long word LOC, must be non-zero. 


Four 8-bit fields, as described below. 


31(MSB) 


Set bit to... 


change input buffer interrupts (bits 1-2). 


enable a single input buffer interrupt, clear to disable. 
Valid only if bit 0 is set. 


enable multiple interrupts, clear to disable. Valid only if 
bit O is set. 


en ees 


acknowledge receipt of interrupt when data is present 
in the input buffer. 


change output buffer interrupts (bits 5-6). 


enable a single output buffer interrupt, clear to disable. 
Valid only if bit 4 is set. 


enable multiple interrupts, clear to disable. Valid only if 
bit 4 is set. 


acknowledge receipt of an interrupt when space is 
available in the output buffer. 
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Returned data 


One of CONAOK, CONERR, CONPRM in the high order 16 bits. 


Four 8-bit fields, as described below. 


Channel 


Name 2 Meaning when bit set 


IPSIE 

OPSIE Output buffer interrupts are enabled. 
Ce 
31 (MSB) There is space in the output buffer. 


Bits 0-7 apply to channel 0, 8-15 to channel 1, 16-23 to channel 2, and 24-31 to channel 3. 


An input buffer interrupt has occurred. 


Input buffer interrupts are enabled. 


Multiple interrupts are enabled. 


fon) 


N NO N N 
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~s 


There is data in the input buffer. 


nN 
eo 


An output buffer interrupt has occurred. 


oO 


Ww N 
Ke} 


Notes 

1. IPSIE and IPMIE are ignored if IPISET is set to O. 
OPSIE and OPMIE are ignored if OPISET is set to 0. 
IPMIE is ignored if IPSIE is set to 0. 
OPMIE is ignored if OPSIE is set to 0. 
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IPSIE and OPSIE are cleared automatically on acknowledgment of an interrupt. 
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Servicing buffers 


There are two ways to use the CHISR service to inform the application software there is a buffer 
for it to service: 


e Interrupt control. Trigger a HUDI interrupt when channel buffer data becomes 
available or channel space is available. 


e Polling. Poll a channel to determine if a transmitting buffer is empty or a 
receiving buffer is non-empty. 


Interrupt control 


The CHISR BIOS call allows the target to interrupt the target if one of these conditions are met: 
¢ Data is in the input buffer for the application software to read and process. 


¢ Space is available in the output buffer for the application software to store data 
in the buffer, ready for the host to read and process. 


You can generate single or multiple HUDI interrupts when a condition is met. Single interrupts 
are generated once-only when an interrupt condition is met. Multiple interrupts are generated 
each time the channel condition is met. 


Notes: 
1. The HUDI is not an ASE mode interrupt. 


2. The HUDI interrupt vectors to the application software interrupt handler. It is the 
responsibility of the application software to ensure this is present. 


3. CHISR can return with more than one ‘interrupt occurred’ bit set. 
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Example BIOS call 


This example shows a typical BIOS call to set up and clear interrupts for the four channels. 


i 


Use the 'set and read interrupts' BIOS call to set up interrupts. 
mov.l #loc,r5 ;Location for set up parameters. 


Channel 0. Operating system. Set for single interrupt on input 
buffer (data available). 

mov.b #(IPISET + IPSIE),r8 

mov.b r8,@r5 


Channel 1. File server. Set up for multiple interrupts on input 
buffer (data available) and output buffer (space available). 
mov.b #(IPSET + IPMIE + OPISET + OPMIE) ,r8 
mov.b r8,@(1,1r5) 


Channel 2. Sound tools. Turn off interrupts. 
mov.b #(IPISET + OPISET),r8 
mov.b r8,@(2,r5) 


Channel 3. Unused. Make no changes to channel 3. 
mov.b #0x00,r8 
mov.b r8,@(3,r5) 


Issue a 'Set and read channel interrupts' BIOS call. 


mov.l1 #CHISR,r4 ;BIOS command 0x900. 
mov.1 #STUBSTART,Yr9 ;Point at the stub start. 
jsr @r9 ;Issue BIOS call. 
nop 

After call: 


Error code returned in high word R8. 
'Loc' contains eight 4-bit fields containing interrupt and buffer 
status. 
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Polling 


The CHISR, “Set and Read Channel Interrupts’, BIOS call can be used to determine the state of 
individual channel buffers. This allows polling to implemented instead of interrupt control. 


Example BIOS call 


This example shows a typical BIOS call to interrogate the four channels’ buffers. 


; Use the 'set and read interrupts' BIOS call to read channel status. 


mov.l #loc,r5 ;Location for set up parameters. 
mov.b #0,r8 

mov.b 4r8,@rr5 ;No change channel 0 

mov.b r8,@(1,r5) ;No change channel 1 

mov.b r8,@(2,5) ;No change channel 2 

mov.b r8,@(3,r5) ;No change channel 3 


; Issue a 'Set and read channel interrupts' BIOS call. 


mov.1 #CHISR,r4 ;BIOS command 0x900. 
mov.1 #STUBSTART,r9 ;Point at the stub start. 
jsr @r9 ;Issue BIOS call. 

nop 


After call: 
Error code returned in high word R8. 
'Loc' contains eight 4-bit fields containing interrupt and buffer 


status. 
mov.l #loc,r5 ;Location for returned parameters. 
mov.b @r5+,r1 ;Current Channel 1 status. 
mov.b @r5+,r2 ;Current Channel 2 status. 
mov.b @r5+,r3 ;Current Channel 3 status. 
mov.b @r5+,r4 ;Current Channel 4 status. 


The registers r1,r2,r3,r4 now contain the details for each channel 
for the following items: 

Input buffer data available/no data available. 

Output buffer space available/no space available. 
and also: 

Input buffer occurred/not occurred. 

Input buffer interrupts enabled/disabled. 

Input buffer multiple interrupts enabled/disabled. 

Output buffer occurred/not occurred. 

Output buffer interrupts enabled/disabled. 

Output buffer multiple interrupts enabled/disabled. 
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Acknowledging receipt of a HUDI interrupt 


You can use CHISR to acknowledge the receipt of an HUDI interrupt. The application interrupt 
handler must include the functionality to acknowledge HUDI interrupts for the following 
reasons: 


1. The HUDI interrupt cannot be guaranteed to be accepted by the SH4. This is a 
characteristic of the SH4 microprocessor. 


2. The interrupt can be lost if the debug stub is entered at the same time as a HUDI 
interrupt is generated, for example when executing a software BRK breakpoint. 


The DA will repeatedly issue HUDI interrupts (when interrupts are enabled) until the application 
software has acknowledged the interrupt by calling CHISR. 


When the application software code HUDI interrupt handler is entered due to an HUDI interrupt, 
the ’set and read channel interrupts’ command with the relevant acknowledge bits set should be 
issued. This will inform the DA that the interrupt has been accepted and prevent it from 
re-issuing the HUDI interrupt again. 


Example BIOS call 


This example shows a typical BIOS call to acknowledge an input interrupt on channel 1. 


; Use the 'set and read interrupts' BIOS call to acknowledge an 


interrupt. 
mov.l1 #loc,r5 ;Location for set up parameters. 
mov.b #0,r8 
mov.b r8,@r5 ;No change channel 0 
mov.b r8,@(2,r5) ;No change channel 2 
mov.b r8,@(3,r5) ;No change channel 3 
mov.b #IPACK,r8 ;Acknowledge interrupt. 
mov.b r8,@(1,r5) 


; Issue a 'Set and read channel interrupts' BIOS call. 


mov.l1 #CHISR,r4 ;BIOS command 0x900. 
mov.l1 #STUBSTART,r9 ;Point at the stub start. 
jsxr @r9 ;Issue BIOS call. 

nop 


After call: 

Error code returned in high word R8. 

'Loc' contains eight 4-bit fields containing interrupt and buffer 
status. 


MeN sete 
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HUDI interrupt handler considerations 


HUDI interrupt handler 


The interrupt associated with channel usage generated by the DA is the HUDI interrupt. This 
causes an SH4 ’interrupt’ category at an offset of Ox600 from the VBR. The application code 
must have a suitable exception handler routine in place to allow the exception to be serviced. 


As with the SH4’s entire on-chip peripheral module interrupts the HUDI interrupt has an 
associated priority to allow masking of interrupts by using the status register interrupt level 
mask bits (SR.IMASK). This priority must be set so that the HUDI interrupt is not masked. The 
register IPRC (interrupt priority register C) facilitates the setting up of the priority for the HUDI. 
It is the responsibility of the application program to ensure that the priority for the HUDI is high 
enough to allow interrupts through. It is recommended that the IPRC value be set to its highest 
level (15) to ensure unplanned masking of this interrupt does not occur. 


It is essential that the on-chip peripheral module interrupt priority level setting is only 
performed when the status register block bit SR.BL is set. This is a requirement of the SH4. 


Within the application code interrupt handler, the INTEVT register must be checked to ascertain 
the source of the interrupt. For the HUDI interrupt the INTEVT will contain 0x600. 


BIOS calls within the HUDI interrupt handler 


The recommended method for implementing a HUDI interrupt handler is: 


1. Issue a CHISR (Set and Read Channel Interrupts) BIOS call to ascertain which 
channel sources caused the interrupt (and whether it was on input and/or output). 


2. For each of the interrupting sources, either: 


- Handle the interrupt immediately by issuing further BIOS channel commands 
to move data between the Host and the target as applicable. 


-OR- 
~ Set flags or signals to inform "background code’ of the interrupt occurring. 


3. Issue a CHISR (Set and Read Channel Interrupts) BIOS call to acknowledge all 
channel sources that caused the interrupt. 


NOTE: The above method assumes that all the normal requirements for the 
implementation of SH4 interrupt handlers are observed. 
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Host channel access 


The CPDIAL communications library provides access to channels from the host. CPDIAL is 
organized as a C++ class called CDial containing objects that each hold an API for a different 
device supported by the library. There are four header files required to use the library with 
channels, the principle header file is dial.h. 


Header file: Contains: 


DialChannel.h 


GenChannel.h 


Connecting and disconnecting 


The CDial class definition and definition of DIALDEVICE. 


The definition of CDialChannel, the base class for the six 
channel-specific classes. Data structures used by CD/ALChannel are 
contained in GenChannel.h. 


The data structures used by DialChannel. 


The DIAL API error code definitions. 


Two functions, Connect and Disconnect establish and release a connection between an 
application and a device. Depending on the type of the device, the nature of the connection can 
be very important. For example, a network device may be accessed by multiple users but an 
active connection provides a user with exclusive access to the device for the duration of that 
connection. 
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NOTE: When a device is first found (using FindNextDevice) it is recommended that a 
connection is made and kept until the device is no longer required. For example, 
CodeScape connects to a device, locally or across a network, at startup and does 
not disconnect from the device until it is shut down. 


Using DIAL 


To initialize and use the library acquire a pointer to the library using InitializeDial function. 


Calling a function 


DIAL requires a ‘magic cookie’ (denoted by DIAL_ID) that the DIAL DLL uses to identify the 
device. The DIAL_ID is usually obtained using the FindNextDevice function. 


Example 


NOTE: This example illustrates the calling convention only; for more examples, see the 
TESTDIAL diagnostic utility and source code provided with CPDIAL. 


// Instantiate the DIAL library once only for any given application 
CDial * pDial = InitializeDial(); 
pDial = GetDial; 


DIAL_EC ecRetCode = DIAL EC_NOERROR; 
DIAL_ID DeviceID = DIAL _ID UNDEF; 


ecRetCode = DIAL->FindNextDevice ( DevicelID, 


DIALDEVICE: : DEVTYPE_KATANA_DA) ; 
// a DIAL root method 


if (ecRetCode == DIAL _EC_NOERROR) 
{ 
ecRetCode = pDial->DA.xxx(DeviceID, ...) // control the DA 
ecRetCode = pDIAL->Console.xxx(DIAL_ID, deviceID, ...) // control the console. 


=— // access the channels. 
ecRetCode = DIAL->FServer.Reserve (DeviceID, ...); 
ecRetCode = DIAL->FServer.Read(DeviceID, ...); 

ecRetCode = DIAL->FServer.Release(DeviceID, ...); 
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CDial functions 


The CDial class contains these functions: 


Function name Purpose 
Initializes DIAL and returns a pointer to the Dial interface. 
GetVersion Returns the library’s version number. 
SetTimeOut Sets the timeout period. 
GetTimeOut Returns the current timeout value. 
FindNextDevice Locate devices on the bus. 


ValidateDevice Tests the validity of a specified device. 
GetErrorText Converts an error code to a strings. 


Connect Makes a connection to a device. 


Disconnect Disconnects from a device. 


Error codes 


The majority of CDial class methods return a 32-bit error code (of type DIAL_EC). The higher 
16 bits is a group code indicating the module, the lower 16 bits is an error code indicating the 
error. Error codes are defined in the file error.h; the construct of the error is not usually required 
to be known. Passing the error code to the GetErrorText function returns a textual description 
of the category and specific error encountered. 
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CDial class definition 


The CDial class definition has the public form. The class CChannel is defined externally to 


CDial in its own definition and implementation files and contains just the routines specific to 
that module. 


class CDial 


{ 
public: 
enum DEBUGMODE 
{ 
DEBUGMODE_OS, 
DEBUGMODE_CPU 
}i 
CDialDAEx& DA; 
CDialConsoleEx& Console; 


// Use these channel wrapper classes in preference to using 
// CChannel directly 


CTypedChannelEx& VSerial; 
CTypedChannelEx& DebugOS ; 
CTypedChannelEx& FServer; 
CTypedChannelEx& Sound; 
CTypedChannelROEx& TraceProfile; 


// Direct access to the CChannel class. 

// Needs specification of channel identifier CHANTYPE enumerated 
// parameter defined in channel.h 

// N.B. CHANTYPE_TRACEPROFILE is *Read Only*, as specified in 

// CTraceProfile API. 

CDialChannelEx& Channel; 


CDial( CDialDAExé& da, 
CDialConsoleEx& console, 
CTypedChannelEx& vserial, 
CTypedChannelEx& debugOS, 
CTypedChannelEx& fileServer, 
CTypedChannelEx& sound, 
CTypedChannelROEx& traceProfile, 
CDialChannelEx& channel 
) : DA( da), 
Console( console ), 
VSerial( vserial ), 
DebugOS( debugOS ), 
FServer( fileServer ), 
Sound( sound ), 
TraceProfile( traceProfile ), 
Channel ( channel ) 
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} 


virtual BOOL 


virtual void 
virtual DWORD 


GetVersion( DWORD&, DWORD& ) const = 0; 


SetTimeOut ( DWORD ) = 0; 
GetTimeOut () const = 0; 


virtual DIAL_EC FindNextDevice( DIAL ID&, 


DIALDEVICE: :DEVTYPE ) = 0; 


virtual DIAL_EC GetDeviceDetails( DIAL_ID, DIALDEVICE& ) = 0; 


virtual DIAL_EC ValidateDevice( DIAL_ID, 


DIALDEVICE: :DEVTYPE = DIALDEVICE: :DEVTYPE_UNDEF ) = 0; 
virtual const char*GetErrorText( DIAL_EC ) = 0; 
virtual DIAL _EC Connect ( DIAL ID ) = 0; 
virtual void Disconnect ( DIAL_ID ) = 0; 
1 
#ifdef DIAL _DEF_ 
extern "C" _ declspec( dllexport ) CDial * InitializeDial(); 
extern "C" _ declspec( dllexport ) DIAL_EC GetDialDebugMode(CDial *, 
DIAL_ID, 
CDial::DEBUGMODE& ) ; 
extern "C" _ declspec( dllexport ) DIAL_EC SetDialDebugMode(CDial *, 
DIAL ID, 
CDial::DEBUGMODE ); 
#else 
extern "C" _ declspec( dllimport ) CDial * InitializeDial(); 
extern "C" _ declspec( dllimport ) DIAL_EC GetDialDebugMode(CDial *, 
DIAL _ID, 
CDial::DEBUGMODES& )j; 
extern "C" — declspec( dllimport ) DIAL_EC SetDialDebugMode(CDial *, 
DIAL_ID, 
CDial::DEBUGMODE ) ; 
typedef CDialDAEx CDA; 
typedef CDialConsoleEx CConsole; 
typedef CDialChannelEx CChannel; 
typedef CDialMirageEx CMirage; 
#endif 
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InitializeDial 


Initializes DIAL and returns a pointer to the Dial interface. 


CDial * InitializeDial(); 


Return value 


A pointer to the Dial interface. 


Parameters 


None. 
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GetVersion 


Returns the library's version number. 


BOOL CDial::GetVersion ( WORD& Major, 


WORD& Minor) ; 


Return value 


Always returns True. 


Parameters 


Major 
The major version number. 


Minor 
The minor version number. 


SH4 Debug Interface 
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SetTimeOut 


Sets the timeout, in milliseconds, for the high-level commands. 
VOID SetTimeOut (DWORD timeout) ; 


Return value 


None. 


Parameters 


timeout 
The timeout value in milliseconds, the default is 5000 milliseconds. 


Remarks 
Sets the timeout value for the channel-specific commands. If a command reports a non-serious 


error, such as BUSY or PENDING, DIAL retries the command or waits for it to be completed 
until the timeout period is reached. 
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GetTimeOut 


Returns the current timeout value for DIAL high-level commands. 


DWORD GetTimeOut (VOID) ; 


Return value 


The current timeout value in milliseconds. 


Parameters 


None. 
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FindNextDevice 


Locate devices on the bus. 


DIAL_EC FindNextDevice ( DIAL _ID& device, 
DIALDEVICE: :DEVTYPE type = DIALDEVICE: :DEVTYPE_INDEF) ; 


Return value 


Returns DIAL_EC_NOERROR on success or an error code otherwise. 


Parameters 


device 
The most recently found device. Use DIAL_ID_UNDFF to find the first device. 


type 
The type of device to find. The default value is ALL. See DIALDEVICE in dial.h 
for a list of device types. 

Remarks 


Use FindNextDevice to find DIAL devices. The caller supplies a device identifier (or 
DIAL_ID_UNDFF to find the first device). On successful return the device identifier of the next 
matching device is set. 


NOTE: Device identifiers are passed by reference and will be modified. 
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GetDeviceDetails 


Supplies details for a specified device. 


DIAL _EC GetDeviceDetails ( DIAL_ID device, 
DIALDEVICE& details) ; 


Return value 


Returns DIAL_EC_NOERROR on success or an error code otherwise. 


Parameters 


device 
A valid device identifer. 


details 
A DIALDEVICE structure where the results are stored. 


Remarks 


See DIALDEVICE in dial.h for supported device types. 


NOTE: The details of a particular device are passed by reference and will be modified. 
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ValidateDevice 


Tests the validity of a specified device. 


DIAL_EC ValidateDevice ( DIAL _ID device, 
DIALDEVICE: :DEVTYPE type = DIALDEVICE: :DEVTYPE_ UNDEF) ; 


Return value 


Returns DIAL_EC_NOERROR on success or an error code otherwise. 


Parameters 


device 
A valid device identifer. 


type 
The type of device to validate. The default is DIALDEVCE::DEVTYPE_UNDEF. 


Remarks 


See DIALDEVICE in dial.h for a list of device types. 
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GetErrorText 

Converts an error code to a string for display purposes. 
const char * GetErrorText (DIAL_EC error) 

Return value 


Returns a pointer to a string containing a textual representation of error. 


Parameters 
error 

The error code to convert. 
Remarks 


None. 
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Connect 


Makes a connection to a device. 


DIAL_EC Connect (DIAL _ID device) 


Return value 


Returns DIAL_EC_NOERROR on success or an error code otherwise. 


Parameters 
device 

The identifier of the device to connect to. 
Remarks 


The device will not be available to other users until it is released using the Disconnect function. 
Each use of Connect must be matched by a corresponding Disconnect call. 


NOTE: Always use the Connect and Disconnect functions connecting to a device. This is 
the most efficient method and guarantees the correct state of the device. 
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Disconnect 

Disconnects from a device. 

void Disconnect (DIAL_ID device) 
Return value 


None. 


Parameters 
device 

The identifier of the device to disconnect from. 
Remarks 


After disconnecting, the device is then available to other users. Each use of the Connect function 
must be matched by a corresponding Disconnect call. 


NOTE: Always use the Connect and Disconnect functions connecting to a device. This is 
the most efficient method and guarantees the correct state of the device. 
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CDial::CDialChannelEx functions 


Typed channels 


DIAL’s channel functions are defined by three classes, CDialChannelEx, CTypedChannelROEx 
and CTypedChannelEX. CDialChannelEx represents a generic channel whereas 
CTypedChannelROEx and CTypedChannelEX represent channels of a particular type. 


CDialChannelEx class definition 


class CDialChannelEx : public CGenChannel 
{ 
public: 
virtual DIAL_EC Reserve( DIAL_ID, 
CHANTYPE, 
DWORD = DIAL DEFAULT_TIMEOUT ) = 0; 
virtual DIAL EC Release( DIAL_ID, CHANTYPE ) = 0; 
virtual DIAL _EC Validate ( DIAL ID, CHANTYPE ) = 0; 
virtual DIAL EC DataReady ( DIAL ID, CHANTYPE, BOOL&, DWORD& ) = 0; 
virtual DIAL EC Read( DIAL_ID, 
CHANTYPE, 
DWORD, 
DWORDE, 
void*, 
BOOL = FALSE, 
DWORD = DIAL DEFAULT TIMEOUT ) 
virtual DIAL_EC Write( DIAL_ID, 
CHANTYPE, 
DWORD, 
DWORDE, 
const void*, 
BOOL = FALSE, 
DWORD = DIAL DEFAULT TIMEOUT ) 


u 
oO 


il} 
oO 
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Reserve 

Reserves the channel specified by type and must be used before any reading or writing is 
performed. 

DIAL_EC Reserve ( DIAL_ID device, 


CHANTYPE type, 
DWORD timeout = DIAL DEFAULT TIMEOUT) ; 


Return value 


Returns DIAL_EC_NOERROR on success or an error code otherwise. 


Parameters 


device 
A valid device identifier. 


type 

A member of the CChannel::CHANTYPE enumeration, specifying the channel. 
timeout 

The length of time to wait for the channel if it is in use by another process. 
Remarks 


When the channel is no longer required, for example when a program exits, a corresponding 
Release call must be made. 


If the channel is currently in use, the length of time Reserve waits for the channel request to 
succeed is specified by DIAL_DEFAULT_TIMEOUT which is set to 5000 milliseconds by 
default. To wait indefinitely, specify INFINITE. 
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Release 


Releases the channel specified by type on the device specified by device for use by other 
processes. 


DIAL EC Release ( DIAL_ID device, 
CHANTYPE type) ; 


Return value 


Returns DIAL_EC_NOERROR on success or an error code otherwise. 


Parameters 


device 
A valid device identifier. 


type 
A member of the CChannel::CHANTYPE enumeration specifying the channel. 
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Validate 


Tests for the presence of the channel specified by type on the device specified by device and is 
reserved for use by this process. 


DIAL_EC Validate ( DIAL ID device, 
CHANTYPE type) ; 


Return value 


Returns DIAL_EC_NOERROR on success or an error code otherwise. 


Parameters 


device 
A valid device identifier. 


type 
A member of the CChannel::CHANTYPE enumeration, specifying the channel. 


Remarks 


None. 
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DataReady 
Determines whether there is any data to read on the specified channel. 
DIAL_EC DataReady ( DIAL _ID device, 


CHANTYPE type, 
BOOL& isData, 
DWORDé& status) ; 


Return value 


Returns DIAL_EC_NOERROR on success or an error code otherwise. 


Parameters 


device 
A valid device identifier. 


type 
A member of the CChannel::CHANTYPE enumeration, specifying the channel. 


isData 
Set to True if data is available in the buffer, False otherwise. 


status 
Holds additional status information on return. 


Remarks 


Currently only the CHANTYPE_TRACEPROFILE channel modifies this value to 
CHANSTATUS_HALFFULL. For all other specified channels, it is returned as 0. 


54 


SH4 Debug Interface 


Read 


Reads a specified amount from the specified channel and returns the actual amount read. 


DIAL_EC Read ( DIAL_ID device, 
CHANTYPE type, 
DWORD size, 
DWORD& sizeRead, 
const void* buffer, 
BOOL blocking = FALSE, 
DWORD timeout = DIAL_DEFAULT_TIMEOUT) ; 


Return value 


Returns DIAL_EC_NOERROR on success or an error code otherwise. 


Parameters 


device 

A valid device identifier. 
type 

A member of the CChannel::CHANTYPE enumeration, specifying the channel. 
size 

The amount of data to read. 


sizeRead 
The amount of data actually read. 


buffer 


A pointer to a buffer to store the result. 


blocking 
Set to True for blocking, False for non-blocking. 


timeout 
The delay before a timeout. 


Remarks 


By default Read is non-blocking. To make a blocking call use the extra parameters blocking 
and timeout. If blocking, the length of time Read waits for the channel request to succeed is 
specified by DIAL_DEFAULT_TIMEOUT which is set to 5000 milliseconds by default. To wait 
indefinitely, specify a value of INFINITE. 
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Write 


Writes from the specified channel to the specified address and returns the actual number of 
bytes read. 


DIAL _EC Write ( DIAL _ID device, 
CHANTYPE type, 
DWORD size, 
DWORD& sizeWritten, 
const void* buffer, 
BOOL blocking = FALSE, 
DWORD timeout = DIAL DEFAULT _TIMEOUT) ; 


Return value 


Returns DIAL_EC_NOERROR on success or an error code otherwise. 


Parameters 
device 
A valid device identifier. 
type 
A member of the CChannel::CHANTYPE enumeration, specifying the channel. 
size 
The amount of data to read. 


sizeWritten 
The amount of data actually read. 


buffer 
A pointer to a buffer to store the result. 
blocking 
Set to True for blocking, False for non-blocking. 


timeout 
The delay before a timeout. 


Remarks 


By default Write is non-blocking. To make a blocking call use the extra parameters blocking 
and timeout. If blocking, the length of time Write waits for the channel request to succeed is 
specified by DIAL_DEFAULT_TIMEOUT which is set to 5000 milliseconds by default. To wait 
indefinitely, specify a value of INFINITE. 
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CDial::CTypedChannelROEx functions 


CTypedChannelROEx class definition 


pf This represents a read-only channel of a specific type 


class CTypedChannelROEx : public CGenChannel 
{ 
public: 
virtual DIAL EC Reserve( DIAL_ID, 
DWORD = DIAL DEFAULT_TIMEOUT } = 0% 
virtual DIAL_EC Release( DIAL_ID ) = 0; 
virtual DIAL _EC Validate( DIAL ID ) = 0; 
virtual DIAL EC DataReady ( DIAL_ID, 
BOOLE, 
DWORD& ) = 0; 
virtual DIAL _EC Read( DIAL_ID, 
DWORD, 
DWORDE, 
void*, 
BOOL = FALSE, 
DWORD = DIAL DEFAULT_TIMEOUT )} = 0; 
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Reserve 


Reserves the channel specified by type and must be used before any reading or writing is 
performed. 


DIAL_EC Reserve ( DIAL_ID device, 
DWORD timeout = DIAL DEFAULT_TIMEOUT) ; 


Return value 


Returns DIAL_EC_NOERROR on success or an error code otherwise. 


Parameters 


device 
A valid device identifier. 


timeout 
The length of time to wait for the channel if it is in use by another process. 


Remarks 


When the channel is no longer required, for example when a program exits, a corresponding 
Release call must be made. 


If the channel is currently in use, the length of time Reserve waits for the channel request to 
succeed is specified by DIAL_DEFAULT_TIMEOUT which is set to 5000 milliseconds by 
default. To wait indefinitely, specify INFINITE. 
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Release 

Releases the channel specified by type on the device specified by device for use by other 
processes. 

DIAL_EC Release ( DIAL ID device) ; 


Return value 


Returns DIAL_EC_NOERROR on success or an error code otherwise. 


Parameters 


device 
A valid device identifier. 
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Validate 


Tests for the presence of the channel specified by type on the device specified by device and is 
reserved for use by this process. 


DIAL _EC Validate ( DIAL _ID device) ; 


Return value 


Returns DIAL_EC_NOERROR on success or an error code otherwise. 


Parameters 


device 
A valid device identifier. 


Remarks 


None. 
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DataReady 
Determines whether there is any data to read on the specified channel. 
DIAL _EC DataReady ( DIAL _ID device, 


BOOLE isData, 
DWORD& status) ; 


Return value 


Returns DIAL_EC_NOERROR on success or an error code otherwise. 


Parameters 


device 
A valid device identifier. 


isData 
Set to True if data is available in the buffer, False otherwise. 


status 
Holds additional status information on return. 


Remarks 


None. 
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Read 
Reads a specified amount from the specified channel and returns the actual amount read. 
DIAL_EC Read ( DIAL_ID device, 

DWORD size, 


DWORD& sizeRead, 

const void* buffer, 

BOOL blocking = FALSE, 

DWORD timeout = DIAL_DEFAULT_TIMEOUT) ; 


Return value 


Returns DIAL_EC_NOERROR on success or an error code otherwise. 


Parameters 
device 

A valid device identifier. 
size 

The amount of data to read. 


sizeRead 
The amount of data actually read. 


buffer 
A pointer to a buffer to store the result. 
blocking 
Set to True for blocking, False for non-blocking. 


timeout 
The delay before a timeout. 


Remarks 


By default Read is non-blocking. To make a blocking call use the extra parameters blocking 
and timeout. If blocking, the length of time Read waits for the channel request to succeed is 
specified by DIAL_DEFAULT_TIMEOUT which is set to 5000 milliseconds by default. To wait 
indefinitely, specify INFINITE. 
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CDial::CTypedChannelEx functions 


CTypedChannelEx class definition 
CTypedChannelEx inherits from CTypedChannelROEx and adds the Write function. 


Jif This represents a read-write channel of a specific type 


class CTypedChannelEx : public CTypedChannelROEx 

{ 

public: 

virtual DIAL EC Write ( DIAL _ID, 

DWORD, 
DWORDE, 
const void*, 
BOOL = FALSE, 
DWORD = DIAL DEFAULT_TIMEOUT ) = 0; 
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Write 


Writes from the specified channel to the specified address and returns the actual number of 
bytes read. 


DIAL_EC Write ( DIAL _ID device, 
DWORD size, 
DWORD& sizeWritten, 
const void* buffer, 
BOOL blocking = FALSE, 
DWORD timeout = DIAL _DEFAULT_TIMEOUT) ; 


Return value 


Returns DIAL_EC_NOERROR on success or an error code otherwise. 


Parameters 
device 

A valid device identifier. 
size 

The amount of data to read. 


sizeWritten 
The amount of data actually read. 


buffer 


A pointer to a buffer to store the result. 


blocking 
Set to True for blocking, False for non-blocking. 


timeout 
The delay before a timeout. 


Remarks 


By default Write is non-blocking. To make a blocking call use the extra parameters blocking 
and timeout. If blocking, the length of time Write waits for the channel request to succeed is 
specified by DIAL_DEFAULT_TIMEOUT which is set to 5000 milliseconds by default. To wait 
indefinitely, specify INFINITE. 
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DIAL error codes 


All error codes are defined as enumerations in error.h. The higher order 16 bits contain the error 
category and the lower order 16 bits contain the actual error code. 


Error categories 


Error Code 


ERRCAT_NOERROR 


ERRCAT_SALSA 


ERRCAT_SALSADACON 


ERRCAT_DA 


ERRCAT_CON 


ERRCAT_WINSOCK 


ERRCAT_UNKNOWN 


No error. 


General errors. 


Additional errors relating to DA and target. 
Errors from DA specific commands. 
Errors from target specific commands. 


Errors Winsock specific commands. 


Errors of unknown origin. 
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SALSA error codes 


Error Code Means 


ERRSALSA_NOTINITED 


Call made to uninitialized layer. 


ERRSALSA_DEVICENOTMATCH Failed to validate the device type. 


ERRSALSA_DEVICENOTFOUND Didn't find requested device. 
ERRSALSA_CHANLNOTALLOCD Logical channel (LUN) not allocated. 


ERRSALSA_NOCHNLAVAIL No more channels (LUNs) available. 


ERRSALSA_MEMALLOCFAIL Memory allocation failed. 


ERRSALSA_BADADAPTER Failed to validate the DA. 


ERRSALSA_BADDEVICEID Failed to validate the device identifier. 


ERRSALSA_ TIMEOUT Timed out on command. 


ERRSALSA_FAILCREATESYNCOBJ Failed to create the device’s synchronization object. 
ERRSALSA_FAILCREATELOCKOBJ Failed to create the device's synchronization control object. 


ERRSALSA_FAILLOCK 


Timed out or bad attempt to lock a synchronization object. 


ERRSALSA_FAILUNLOCK 


ERRSALSA_BADVERSION 
ERRSALSA_DEVICEINUSE The specified device is already in use. 
ERRSALSA_NOTIMPLEMENTED The specified function has not been implemented. 


Failed attempting to unlock a synchronization object. 


The version passed to SALSA. Initialise does not match the version 
used to build the library. 
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SALSADACON error codes 


Error Code 


ERRSALSADACON_CMDPENDING 


Means 


Command still pending completion. 


ERRSALSADACON_CMDNOMATCH 


Returned command header did not match in 
command field. 


ERRSALSADACON_SEQNOMATCH 


ERRSALSADACON_FLSHOPENFAIL 


ERRSALSADACON_FLSHSTATFAIL 


ERRSALSADACON_FLSHSHORTREAD 


ERRSALSADACON_BADELEMENTSIZE 


ERRSALSADACON_NOCONPOWER 


ERRSALSADACON_RESETINGCON 


Returned command header did not match in 
sequence field. 


Failed to open flash image file. 


Failed to fstat() flash image file. 


Short read from flash image file. 


The target is currently powered off. 

The target is currently being reset (Reset pin low). 
One of the debug stubs failed to load. 

The ASE RAM debug stub failed to load. 

The Extended debug stub failed to load. 


No debug support available. 


Bad ELEMENTSIZE specified in ReadMemory() or 
WriteMemory/(). 
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DA error codes 


Error Code 
DAERRDA_DAAOK Command completed without an error. 


DAERRDA_DATMO DA Command timed out during action. 


DAERRDA_DAERA DA Command error while erasing firmware. 


DAERRDA_DAPRG DA command error during reflashing. 


DAERRDA_DAFIC DA Command firmware image corrupt. 


DAERRDA_DAERR DA Command general error. 


Console error codes 


Error Code Means 


DAERRCON_CONAOK Console command completed without an error. 
DAERRCON_CONERR Console command fatal error. 


DAERRCON_CONBAD Console command unknown. 


DAERRCON_CONPRM Console command parameter error. 


DAERRCON_CONADR Console command bad address. 


DAERRCON_CONCNT Console command bad count. 


DAERRCON_CONCBF Console command channel buffer full. 


DAERRCON_CONCBE Console command channel buffer empty. 


DAERRCON_CONBSY Console command not processed as BUSY. 


DAERRCON_CONCNA Console command not available (no debug stub). 
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WINSOCK error codes 


Error Code 


ERRWINSOCK_INVALIDVERSION 


ERRWINSOCK_CANTCONNECT 
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Means 


The version of the Winsock library is invalid. 


Unable to connect to the specified device. 


UNKNOWN error codes 


Error Code 


ERRUNKNOWN_UNKNOWNERR 


Error of unknown origin. 
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Appendix A: Writing an SH4 
Boot ROM 


Two basic requirements of the Boot ROM 


Optionally the debugging system may be run with a Boot ROM on the target, allowing a faster 
reset than may be obtained by using Java scripts to set up the RAM and peripherals. Also, this 
start-up code may be a program under development intended to run when the DA is not 
connected. As far as the debugging system is concerned, such a Boot ROM has two basic 
requirements. 


Full details of how to implement the options for loading the debug stub are given in the "Getting 
Started for DASH3 and DASH4”. 


To recognise the special reset exception code 


When the SH4 is reset and the DA performs an ASE debug stub load, the exception event register 
EXPEVT is loaded with a value so that the Boot ROM can recognise the source of the reset. The 
values are shown in the following table: 


Type of reset Execution address contents of EXPEVT 


Target power-on reset OxA000 0000 0x0000 0000 


Target push-button reset | OxA000 0000 0x0000 0020 
(manual reset) 


DASH Debug reset OxA000 0000 0x0000 OFFF 
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The DA causes the debug reset, and everything apart from EXPEVT is reset as for a power-on 
reset. 


The Boot ROM should examine the contents of EXPEVT to determine whether the DA is 
connected and active. If the contents of EXPEVT are equal to 0x0000 OFFF at reset, the Boot 
ROM should issue a BIOS call to load the Extended debug stub. If the contents of EXPEVT are 
not equal to 0x0000 OFFF at reset, then no further debugging operations should be done, in 
particular, the BRK instruction should not be used. 


To instruct the DA where to load the Extended debug stub 


After reset, the Boot ROM should configure RAM and then request the DA to load the Extended 
debug stub. The Extended debug stub is required in order to operate CodeScape correctly and 
to provide fast communications for other functions such as file serving. 


The Extended debug stub requires 16K of RAM and must be loaded using an address in the P2 
address space. This address is important as it will be used later for ASE BIOS calls. We will call 
this address ASE_BIOS. 


To load the Extended debug stub, the SH4 must be running in privileged mode. This is the 
default after reset. The steps are as follows: 


1. Load the R4 register with zero. 


2. Load the register R5 with the address of a six-byte location CHECK_LOC to hold 
version information. 


3. Load the register R6 with the address to load the debug stub (ASE_BIOS). 
4. Execute the BRK instruction. 

5. Examine the RO register and check that it contains 2429814 (decimal). 

6. Save the data returned at CHECK_LOC for later use if required. 


The address ASE_BIOS must be in the range OxA000 0000 to OxBFFF C000, i.e. the start of a 
16K area entirely in the P2 address space. The address must also be on a long word boundary, 
ie. the two least significant bits must be zero. 


72 


SH4 Debug Interface 


If the version information is not required, then R5 should be zero before the BRK instruction is 
executed. Otherwise, data is returned as follows: 


CHECK_LOC Debug Stub ASCII version number 
CHECK_LOC+1 Debug Stub ASCII revision number (2 bytes) 
CHECK_LOC+3 Debug Stub ASCII revision letter 


CHECK_LOC+4 Checksum (binary addition of debug stub) (word), should be 0x0000 for valid 
stub 


When the six steps are complete, the Extended debug stub is in memory and ASE BIOS services 
are ready to use, see “ASE BIOS services” on page 19. 
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Example Boot ROMs 


NOTE: These example Boot ROMs are available on the CodeScape CD. 


Example Boot ROM (without BIOS call request) 


Project: 


Author: 


Ot ttt 


oard. 


bootroml 


bootroml1.sh4 
DASH4 


Description: Example Boot ROM for an SH4 based board. 


George Andrew Taylor 


Initial Coding:27/04/99 
This example code shows a simple example of a Boot ROM for a SH4 


1) Clear the block bit. 

) Set up the SDRAM. 

) Set the SDRAM to a known value. 
) Loop continuously. 


; Clear the BL bit. 


stc 


ak 


sr ,x0 


mov.1 #~SH4 SR.BL,r1 
and.l r1,r0 


ldc 


r0,sr 


; Set up the SDRAM 


mov. 
mov. 
mov. 
mov. 
mov. 
mov. 
mov. 
mov. 
mov. t 
mov. 


Z 


HH 


#ADDR_MMUCR,r1 
#0x00000000,r0 
r0,@r1 
#ADDR_CCR,r1 
#0x00000000,r0 
r0,@rl 
#ADDR_BCR1,r1 
#0x0002c008,r0 
r0,@r1 
#ADDR_BCR2,r1 
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mov. 
mov. 
mov. 
mov. 
mov. 
mov. 
mov . 
mov . 
mov. 
mov. 
mov. 
mov. 
mov . 
mov. 
mov. 
mov . 
Mov. 
mov. 
mov. 
Mov . 
mov. 
mov. 
mov . 
mov. 
mov. 
mov. 
mov. 
mov. 
mov. 
mov. 
mov. 
mov. 


; Loop read RFCR until contents greater than 8. 


JH PPPs = 


1p b + 


PREROSHPRRPRPESEHE SHES rPE SHH 


#0x0000,r0 
r0,@r1l 
#ADDR_WCR1,r1 
FORLLIIL ITTY , 20 
r0,@r1 
#ADDR_WCR2,r1 
#0x018060d8,r0 
r0,@rl 
#ADDR_WCR3,4r1 
#0x07777777,r0 
r0,@rl1 
#ADDR_RTCSR,¥r1 
#0xa510,r0 
r0,@rl 
#ADDR_RTCOR,Y1 
#0xa546,r0 
r0,@rl 
#ADDR_RTCNT,Yr1 
#0xa500,4r0 
r0,@rl 
#ADDR_RFCR,r1 
#0xa400,r0 
r0,@rl 
#ADDR_MCR,r1 
#0x80123410,r0 
r0,@rl 
#O0x££940190,r1 
#Oxff,r0 
r0,@rl 
#ADDR_MCR,¥r1 
#0x80123414,r0 
r0,@r1 


mov.1 #ADDR_RFCR,r1 

mov.l #8,r2 
@sdramlmov.w @r1,r0 

cmp/hi r2,r0 

bf 


mov. 
mov. 
mov. 
mov. 
Mov . 
mov. 
mov. 
mov. 
mov. 
mov. 
Mov. 
mov. 
mov . 
mov. 
mov. 
mov. 


PESrPrEtEterseetrosrrrr 


@sdram1 
#ADDR_MCR,r1 
#0xC0123410,r0 
r0,@rl 
#Ox££940190,r1 
#OXEE, x0 
r0,@rl1 
#ADDR_RTCSR,r1 
#0xa510,r0 
r0,@rl 
#ADDR_RTCOR,Yr1 
#0xa546,r0 

£0 ,@r1 
#ADDR_RTCNT,4r1 
#0xa500,r0 
r0,@rl 
#ADDR_RFCR,r1 
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Appendix A: Writing an SH4 Boot ROM 


mov.w #0xa400,r0 
mov.w 4r0,@rl 

mov.l1 #ADDR_MCR,r1 
mov.1 #0x80123414,r0 
mov.l1 r0,@rl 


; Loop read RFCR until contents greater than 8. 
mov.1 #ADDR_RFCR,r1 
mov.1 #8,r2 

@sdram2 mov.w@rl1,r0 
cmp/hi r2,r0 


bf @sdram2 
; Initialise the SDRAM to a known value. 
mov.l1 #0xac000000,r1 ;Start address. 
mov.l1 #0x40000,r2 ;Number longs to write. 
mov.1 #0xa5a5a5a5,r0 ;Fill value. 
@fill mov.1l r0,@r1 SPAT De. 
add.1 #4,r1 ;Point next. 
dat 2 ;Dec test. 
bf @fill ;Bra if more. 
; Spin 
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SH4 Debug Interface 


Example Boot ROM (with BIOS call request) 


File: bootrom2.sh4 

Project: DASH4 

Description: Example Boot ROM for an SH4 based board. 
Author: George Andrew Taylor 


Initial Coding:27/04/99 


; This example code shows a simple example of a Boot ROM for a SH4 
board. 

a.) Clear the block bit. 

2) Set up the SDRAM. 

3) Set the SDRAM to a known value. 

4) Issue a BIOS call to request the full stub to be loaded. 

5) Loop continuously. 


opt evat 
proc sh4 
org 0x00000000 
nolist 
include defssh4.equ 
list 
; bootrom2 
bootrom2 
; Clear the BL bit. 
Bia.) sr,60 
mov.l #~SH4_ SR.BL,r1 
and..l x1,x0 
ldc rO; Sr 


; Set up the SDRAM 

mov.l #ADDR_MMUCR,r1 
mov. #0x00000000,r0 
mov. r0,@rl 

mov.1 #ADDR_CCR,r1 
mov. #0x00000000,r0 
mov. r0,@r1 

mov.1l #ADDR BCR1,r1l 


th 


HH +t 


mov.l #0x0002c008,r0 
mov.1 r0,@rl 

mov.l #ADDR_BCR2,r1 
mov.w #0x0000,r0 
mov.w r0,@rl 

mov.1l #ADDR_WCR1,r1 
mov.l #0x11111111,r0 
mov.1 r0,@rl 

mov.1 #ADDR_WCR2,r1 
mov.1 #0x018060d8,r0 
mov.1 4r0,@rl 

mov.1 #ADDR_WCR3,r1 
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er 


#ADDR_MCR,r1l 
#0x80123414,r0 
r0,@rl 


mov.l1 #0x07777777,xr0 
mov.l r0,@rl 
mov.1 #ADDR_RTCSR,r1 
mov.w #0xa510,r0 
mov.w 4r0,@rl 
mov.1 #ADDR_RTCOR,r1 
mov.w #0xa546,r0 
mov.w r0,@rl 
mov.1 #ADDR_RTCNT,r1 
mov.w #0xa500,r0 
mov.w 4r0,@r1 
mov.l1 #ADDR_RFCR,r1 
mov.w #0xa400,r0 
mov.w 4r0,@rl 
mov.1 #ADDR_MCR,r1l 
mov.1 #0x80123410,r0 
mov.1 r0,@r1l 
mov.l1 #0xf£940190,r1 
mov.w #0xff,r0 
mov.b r0,@rl 

me 

eal: 

| 


; Loop read RFCR until contents greater than 8. 
mov.1 #ADDR_RFCR,r1 
mov.1 #8,xr2 
@sdraml mov.w@rl1,ro 
emp/hi r2,r0 
bf @sdraml 
mov.1 #ADDR MCR,r1 


mov.1 #0xc0123410,r0 
mov.l r0,@rl 

mov.l #0xf£940190,r1 
mov.w #0xff,r0 

mov.b r0,@rl 

mov.1 #ADDR_RTCSR,r1 
mov.w #0xa510,r0 
mov.w r0,@rl 

mov.l1 #ADDR_RTCOR,r1 
mov.w #0xa546,r0 
mov.w r0,@rl 

mov.1 #ADDR_RTCNT,r1 
mov.w #0xa500,r0 
mov.w r0,@rl 

mov.1 #ADDR_RFCR,r1 
mov.w #0xa400,r0 
mov.w xr0,@rl 

mov.1 #ADDR_MCR,r1 
mov.l #0x80123414,r0 
mov.1l r0,@rl 


; Loop read RFCR until contents greater than 8. 
mov.1 #ADDR_RFCR,r1 
mov.1 #8,r2 
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@sdram2mov.w @r1,r0 


@fill 


emp/hi r2,r0 


bf @sdram2 
; Initialise the SDRAM to a known value. 
mov.l1 #0xac000000,r1 ;Start address. 
mov.1 #0x40000,r2 ;Number longs to write. 
mov.l1 #0xa5a5a5a5,r0 ;Fill value. 
mov.l1 r0,@rl eFil at. 
add.l1 #4,r1 ;Point next. 
dt r2 ;Dec test. 
bf @fill ;Bra if more. 


, 


Now issue BIOS call if EXPEVT = Oxfff. 


mov.1 #ADDR_EXPEVT,r1 

mov.1 @r1,r0 Get contents. 
mov.1 #0xfff,r2 

emp/eq r0,r2 


bf @loop ;Don't issue call! 
; Issue BIOS call 
mov.l #0,r4 ;Must be zero. 
mov.1 #0,r5 ; 
mov.l1 #0xac008000,r6 ;Address to load stub. 
brk 
; Spin 
@loop nop 
bra @loop 
nop 
; lits 
align 4 
lits 
end 
Le aie end of file----------------------7-7--- 
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